home *** CD-ROM | disk | FTP | other *** search
- Path: news.muc.de!hwg!heinz
- Subject: Re: Final Writer 5 Features
- Newsgroups: comp.sys.amiga.applications
- References: <woody-0904961439260001@woody.softwood.com> <xbRj0MD30Aaez3@galdor.papa.north.de> <4kof6b$1b5@news.tiac.net>
- Organization: Private
- Distribution: world
- X-Newsreader: TIN [AMIGA 1.3 950726BETA PL0]
- From: heinz@hwg.muc.de (Heinz Wrobel)
- Message-ID: <heinz.17uj@hwg.muc.de>
- Date: Fri, 19 Apr 96 15:35:08 GMT
-
- David Meyer (dmeyer@tiac.net) wrote:
- >part of a large document. This is somewhat true of any editor with even
- >the most minimal page formating features, like word wrap or page break,
- >but the WYSIWYG programs suffer more and those with a multitude of
-
- This is not really fully correct. A WP/editor does not have to be
- noticably slower when editing the start of a larger text.
- Considering a reasonable WP text memory implementation, a WP has to
- relayout more than the current paragraph only when the line count
- changes. Let's assume that we add or delete a line in the beginning
- of a document with n pages. This means that we have to check at
- most n+1 paragraphs for a relayout and even there we don't actually
- have to fully relayout the current text in the current paragraph.
- The other n paragraphs only need to be updated in terms of the page
- break location. All the paragraphs that don't need to be checked
- for a relayout at a page break only need to be updated via a Y
- offset addition which needs to be updated itself at most once per
- page. Assuming that we use a linked list of paragraphs (of course
- we do, don't we?), we'd need an estimated 2*(n+1) list insertions
- deletions and n+1 field updates for a reasonable implementation. No
- lengthy text fit or length calculations involved at all as the
- line representation of a vertically moved paragraph doesn't change
- at all. For anchored or text flow graphics, additional calculations
- are obviously needed. But even there it can usually be reduced to
- placement checks and Y coordinate or list position updates. No need
- to move large memory blocks. And if a forced page break is inserted
- after a paragraph on e.g. page n/2, it might very well be that we
- can cut short all the calculations at page n/2 beause the following
- pages won't change. For page cross references, we can avoid an n!
- like update algorithm by remembering them in a list and do one
- final linear update. For typical documents, I feel that 1ms per
- paragraph update (not relayout) on an A3k is plenty. That is only a
- "top of my head worst case" feeling, so you'd notice a bad slowdown
- per line insertion only for fairly huge sections. It is probably
- easy to cut down the typical check to a lot less than 1ms per page.
-
- Note that display time is needed only once, and even there it is a
- partial screen scroll, and an update of the scrolled areas. Display
- time is not an issue here.
-
- So if a WP gets slow on large amounts of text, the implementation
- for internal text memory handling needs to improved. I know that
- FW4 currently has this problem and I hope that something has been
- done about it for FW5. I do not say "it so easy to fix this or
- that" because I know it hardly ever isn't. I hope for the best,
- though, because I'd like to use FW for larger documents, too. I
- don't like to start a new section every 10 pages. :^)
-
- Two other annoying things that I hope to see fixed is that marking
- text with the keyboard is wasting my time with really excessive
- block marker redraws and that I can't configure the keyboard
- mapping. I'd like to change at least the qualifiers for
- cursor key movement.
-
- >FW5 in our hands first before we start pleading for more. Woody & crew
- >were pretty good about the FW5 lists posted here.
-
- Yes. I'll update as soon as possible, too. I like FW.
-
- --
- Heinz Wrobel Private Mail: heinz@hwg.muc.de
- My private FAX: +49 89 850 51 25, I prefer email
-